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SABLE  is  •  design  automat  ten  system  currently  being  developed  at 
Stanford  University  to  support  structured,  multi-  level  simulation  of 
computer  designs.  SABLE  stands  for  Structure  And  Behavior  Linking 
Environment,  because  it  joins  information  about  the  interconnectivity  of 
components  with  algor ithmet ic  spec i f icat ions  of  their  behavior.  The 
user  expresses  interconnect ivity  via  SOL  (Structural  Design  language  ) 
IVCU77).  which  has  facilities  for  defining  multiple  levels  of  physical 
hierarchy.  Component  behavior  is  specified  in  ADLIB  (A  Design  language 
for  Indicating  Behavior),  which  is  a  superset  of  the  language  PASCAL 
IJK7A).  ADLIB  was  designed  to  simplify  the  description  of  commonly  used 
computer  components  and  to  ba  compatible  with  SDL  and  SABLE.  ADLIB  was 
never  intended  to  ba  a  programming  language  completely  by  itself. 

This  manual  is  divided  Into  three  partst  an  introduction  to  ADLIB 
with  a  informal  description  of  the  basic  featuresi  a  more  detailed 
discussion  of  the  structure  of  an  ADLIB  program,  including  scoping  rule 
and  contour  models:  and  a  summary  of  the  keywords  end  syntax  of  the 
language.  Because  document  at i on  is  widely  available,  this  manual  will 
not  repeat  the  detailed  features  of  PASCAL.  However,  the  basic  aspects 
of  PASCAL  will  be  described  briefly,  so  that  readers  familiar  with  other 
high  level  languages  should  be  able  to  follow  the  discussion  without  too 
much  di f  f ieul ty. 
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CHAPTER  1 
BASICS  OP  ADLIB 


I . 1  PURPOSE  OP  ADLIB 

Th«  purpoj*  of  an  ADLIB  description  is  to  define  the  behavior  of 
one  or  wore  types  of  computer  components.  The  SABLE  system  then 
combines  these  with  information  that  specifies  the  number  of  components 
used.  and  the  way  they  are  connected.  This  topological  information  is 
expressed  in  SDL.  For  convenience  the  user  may  generate  the  SDL 
aut omat leal ly  via  an  interactive  graphical  structure  editor  called  SUDS2 
IUS7BI  . 

In  ADLIB,  the  code  that  defines  the  behavior  of  one  type  of 
component  is  called  a  comp type .  There  is  no  way  of  telling  from  an 
ADLIB  source  how  many  componants  of  each  comptype.  if  any.  will  be  used 
in  a  design.  Each  comptype  written  in  ADLIB  is  a  specification  of  the 
inout  to  output  function  of  one  type  of  component.  Essentially  all 
information  that  passes  through  a  component  must  go  through  well  defined 
I/O  interfaces  called  "nets."  SABLE  later  connects  these  nets  to  the 
nets  of  other  components  as  directed  by  the  user  via  SDL. 

Before  we  enter  into  any  explanations  of  ADLIB  and  SABLE,  it  might 
be  helpful  to  give  a  small,  useless  but  complete  example.  Me  will 
define  a  tiny  system  consisting  of  a  dealer  and  a  player.  the  dealer 
sends  random  integers  to  the  player,  who  Just  receives  them  and  writes 
the  results  on  the  terminal.  The  ADLIB  code  for  this  looks  like: 
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PROGRAM  •xmp | ; 

NETTYPE 

Intnat  : integer; 

•include  rpalcs.dcl  {include  a  lil*  of  routine  dec  I  nr  at  i  on* 

COMP  TYPE  deal  or ; 

OUTWARD 

cardout  :  tntnet; 

VAR 

I  i  integer; 

BEGIN 

WHILE  t  rut  DO  BEGIN 

ASSIGN  rnd I nt ( I, 13)  TO  cardoutt 
WA1TF0R  (rue  DELAY  I . 0 | 

ENO; 

END; 

COMPTYPE  playarj 
INWARD 

cardin  t  intnott 
BEGIN 

WHILE  true  DO  BEGIN 

WAITFOR  true  CHECK  cardin; 
writeln(tty.cordin); 

END; 

END; 

BEGIN 

END. 


The  ilructur*  of  (hit  System  it  shown  balowi 


I 
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SOL  code  to  used  dt»crtb»  the  interconnect  ivity  of  this  system  i»i 

NAME:  TEST; 

TYPES  Ideeier. player: 
dealer  i  Joe: 
player  t  ralph; 

END: 

NETSEGflENT; 

net  1  *  joe. cardout .ralph. cardin: 

ENCNETS: 

EndC: 

CEND;  , 


Whan  this  code  it  compiled  and  executed.  the  result  is  a  never 
and i ng  stream  of  random  integers  between  1  and  13  (inclusive)  directed 
to  the  terminal.  I*  the  example  makes  sense.  fine.  If  not,  don’t 
worry.  The  remender  of  this  paper  will  explain  and  elaborate 
every) hi ng 


1.2  INTRODUCTION  TO  THE  NEW  ADLIB  CONSTRUCTS 


Because  ADLIB  is  a  superset  of  PASCAL.  it  includes  all  of  the 
PASCAL  control  statements.  For  readers  not  familiar  with  these 
statements  they  are  summarized  here. 


1.2.1  Review  Of  PASCAL  Constructs 


1.  IF  (boolean  expr>  THEN  <stmtl>  ELSE  <stmt2> 
which  chooses  between  two  alternative  statements: 

2.  CASE  <expr >  OF  <valuet>i<stmt 1> 

<value2>:<stmt2> 

END 

which  selects  one  of  an  arbitrary  number  of  statements,  (similar  to. 
but  more  powerful  than  a  "switch"  or  "computed  goto"); 

3.  WHILE  (boolean  expr>  DO  (stmt> 

which  iterates  a  statement  zero  or  more  times; 

A.  REPEAT  (stmt)  UNTIL  (boolean  expr> 

which  iterates  a  statement  one  or  more  times: 
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5.  FOR  <var tabl •> i *<expr 1 >  T0<expr2>  DO  <stmt> 

which  repetitively  executes  a  statement  as  <veriable>  ranges  from 
<e«prl>  to  <expr2>.  (Similar  to  «  FORTRAN  DO  loop.) 

6 .  GOTO  < label > 

which  transfers  control  to  <!abel>  unconditionally*. 


1.2.2  Additional  ADLIB  Constructs 

The  above  six  constructs  are  useful  for  defining  the  algorithm 
incorporated  within  a  component •  but  are  not  adequate  for  describing 
int er-component  control  and  data  flow.  Therefore.  the  following  new 
constructs  have  been  added  to  ADLIB’ 

1.2.2. 1  ASSIGN  <ewpr>  TO  <net  na«e>  <timing  clause) 

Assign  evaluates  <expr>  and  stores  the  result  away  in  a  hidden 
area.  At  a  later  time.  this  value  is  retrieved  and  assigned  to  t  lie 
specified  net.  Time  delays  may  be  specified  in  several  ways  depending 
on  the  nature  of  the  circuit  (synchronous  or  asynchr onous )  and  the 
objectives  of  its  designer.  The  simplest  way  is  to  define  a  delay 
directly,  as  for  example: 

ASSIGN  true  TO  out  DELAY  15. J) 

Fifteen  and  three  tenths  simulated  time  units  after  this  statement  is 
executed.  the  net  "out"  will  be  updated  to  the  value  "true".  Time 
delays  need  not  be  constants,  any  real  expression  may  be  used.  For 
example,  if  two  parallel  paths  exist  to  the  same  outward  connection,  and 
either  one  is  sufficient  to  drive  it,  than  wa  could  define  the 
component’s  behavior  ast 


•This  construct  is  current ly  out  of  fashion. 
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ASSIGN  result  TO  out  DELAY  m I n(  del ay_t . del ay_2 > 

("Bin"  it  a  fund  ion  th«(  rtlurni  t ho  ■initun  of  it*  (rguntnti. ) 

the  expression  in  on  ASSIGN  statement  way  contain  function  Cal  It. 
For  example.  in  ordar  to  datcriba  a  signal  ganirator.  it  tt  convaniant 
to  wr it  a: 


ASSIGN  t in( t i «a*f raquancy )  TO  ai9nalout 

Thit  statement  iltuatratat  two  other  pointt  at  wall.  In  ADLIB,  t ha 
variable  **t  tae"  always  containt  t  ha  currant  valua  of  t  ha  simulation 
time.  Whan  t ha  simulation  begins,  it  it  aqual  to  0.0.  Utar  assignment 
to  "time"  ratultt  in  a  compilation  arror  message.  Alto,  thit  statement 
doat  not  contain  an  explicit  DELAY  clauta.  T ha  ADLIB  compiler  tharafora 
traatt  it  at  if  DELAY  0.0  uara  tpacifiad.  At  firtt  glanca.  r«r« 
propagation  datay  t iaat  may  taan  confuting,  unraaliatic.  and  potantially 
hazardous.  Howtvtr,  bacauta  of  t ha  runt iaa  organization  of  SABLE,  thit 
oparat ion  it  unambiguous  and  utaful.  During  tiaulation.  SABLE  cyclat 
batwaan  t ha  execution  of  coaponant't  behavior  descriptions  and  tha 
updating  of  tha  not t  connacting  them.  Firtt.  all  coaponantt  ara  allowad 
to  execute.  'than  all  nat  t  ara  updatad.  than  all  coaponantt  ara  allowad 
to  execute  again,  ate.  Ona  itaration  of  thit  cycla  conatitutat  ona 
t< »n t .  It  aay  happan  that  tavaral  avant t  occur  sequent ial ly •  but  at  tha 
ta-"a  simulated  time.  If  ona  or  e«r«  coaponantt  attign  to  a  tat  of  nat  t 
with  a  DELAY  of  0.0.  than  all  thata  update*  will  appaar  to  occur 
t iaul t  anaout ly . 

No  hazards  or  racat  ara  tntroducad  by  allowing  itr«  propagation 
dalay.  and  ih*r»  are  tavaral  applicationt  whara  it  it  in  fact,  nacattary 
and  appropriata.  For  avamola.  a  datignar  way  prefer  to  traat 
co«b i nat ional  logic  at  oparating  with  zero  t iaa  dalay.  to  contraat  tt 
with  tha  sequent ial  circuitry.  At  an  extreme  example  of  thit,  consider 
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»  *v»t*m  i«plt*(ni«d  with  relay*.  We  wi»h  To  eapreit  the  idea  that  a 
voltage  propagate*  through  the  contact*  of  a  relay  immeasurably  latter 
(measured  In  neno'lecond*)  than  the  *peed  at  which  the  armature  wove* 
(weatured  in  m 1 1 1  I -second* ) ,  To  describe  a  relay  which  operate*  a*  a 
•ingle  pole,  double  throw  switch  (like  a  one  bit  multiplexor),  we  could 
write) 

IF  armature  position  *  uo  THEN  ASSICN  input  I  TO  out 
ELSE  ISSIGN  input  2  TO  out 

In  the  above  example-  the  exact  speed  ot  propagation  is 

incalculable  and  irrelevant  (in  fact,  it  would  probably  be  lost  to 

round-ott  error).  On  the  opposite  extreme  are  circuit*  who**  output 
value*  aust  be  available  at  precisely  controlled  instant*,  l.e. 

synchronous  circuit*.  For  example,  moot  a i cr o-cont ro I  I er *  operate  at  a 
precisely  constant  speed  independent  ot  the  micro* tnst ruct ion  mix  (thi* 
ts  not  generally  true  ot  macro* instruct  ion*) .  Such  controller*  and  any 
circuitry  directly  connected  with  them  are  mo*t  conveniently  defined  in 
ADLIB  with  the  us*  of  a  CLOCK  and  the  SYNC  priaitlv*.  An  ADLIB  clock 
•ay  be  thought  of  as  a  function  that  maps  simulation  time  Into  positive 
integers.  At  time  0  all  clock*  have  vatu*  0.  A*  simulation  time 
progresses.  t h*  clocks  run  through  their  phases  repetitively: 

9  . 1 . 2 . J . • . t . t . 5 . • . t . 2 . S . . .  etc.  for  a  tour  phase  clock.  The  period  of 
repetition  I*  the  parameter  value  specified  by  the  user  in  t  he  clock 
definition  statement.  The  value  o*  clock  "elk."  defined  a*: 

CLOCK  clk(6.0.A)> 

i*  shown  in  figure  t. 

By  us*  of  th*  SYNC  operator,  t he  user  can  synchronise  an  operat ion 
with  a  particular  leading  edge  of  a  clock.  For  example,  a 
m  lero*cont ro 1 1 er  might  have  to  have  several  control  line*  ready  at 
precisely  the  leading  edge  of  the  number  one  phase  of  clock  "micro_clk". 
Thi*  could  be  written  as: 
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TINE  -> 

FI'-^JBC  11  VAIL*  Of  CLJC<4.«,4> 


r  !*  nicro*tor*taicro_ip} S 
■lero  ip  : :  micro_ip  ♦  It 

ASSIGN  r.  carry  TO  line!  SYNC  inter©  elk  PHASE  is 
ASSIGN  r.thifiO  TO  I  »r>©2  SYNC  nierS  elk  PHASE  Is 

ASSIGN  r . shi f  t  I  TO  I in*J  SYNC  micro'elk  PHASE  Tj 

ASSIGN  r .shift?  TO  I in*4  SYNC  «*lcro"clk  PHASE  Is 

ASSIGN  r . c l ear  TO  1 in*5  SYNC  latero  elk  PHASE  t; 

(••tc.4) 

All  of  the  abova  ASSIGN  statement*  Mill  bo  ©ff©cl©d  at  precisely  tb* 
ten©  simulated  tin*. 

Tb©  vi*r  nay  specify  *ny  number  of  ind©p©nd©nt  CLOCK*.  ©»ch  Mitb 
tb©tr  own  ported*  ©nd  number*  of  pbatot.  Unlike  tome  other  timuletion 
env I r onment t ,  clock*  do  not  contum©  any  computation  retource* 
t  bemte  I  ve* :  only  when  ©nd  it  a  component  eccettet  them  it  any 
calculation  performed.  Tb*  uier  may  nark  one  of  t be  clock*  a*  being  t  he 
default.  Tht*  save*  him  or  her  from  writing  t be  c 1 ock * •  name  in  every 
*yne  clause.  Alto,  if  no  phete  it  tpecified.  t be  compiler  ettumet  that 
phase  0  i*  intended.  It  i*  therefore  quite  convenient  to  describe 
tytiemt  that  maintain  a  tingle  universal  clock,  *uch  at  a  pipelined 
multiplier  that  keep*  each  stag*  in  lock  step  with  the  others. 
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1.2.?.?  UAITFOR  <booI»«n  («pr>  (control  clause> 

UAITFOR  cautti  »«»cul ion  of  a  coaiponanl ' s  coda  to  atop.  and  does 
not  allow  it  to  cont inuo  until  (boolean  *«pr>  evaluates  to  true.  The 
(control  clause>  way  come  in  one  of  two  form*.  Firat.  a  (timing  clauae> 
may  be  used,  just  like  the  timing  clauae  in  an  ASSIGN  atatement.  If  a 
delay  clause  if  used,  the  (boolean  expr>  is  raevaluated  periodically  at 
the  period  specified  in  the  delay  clausa.  For  example: 

UAITFOR  current >0 . 00  I  DELAY  samp  1 e_per i od i 

This  statement  would  check  the  value  of  "currant"  every  "sampla_par iod" 
tine  units,  until  it  exceeded  one  milliamp. 

If  SYNC  is  specified,  t  he  (boolean  expr>  is  reevaluated  each  time 
the  specified  clock  goes  through  the  specified  phase.  For  example: 

UAITFOR  acknowl edge: I  SYNC  bus.clock  PHASE  A; 

This  statement  would  not  allow  execution  to  continue  until  the  net 
"acknowl edge"  was  equal  to  I  on  the  leading  edge  of  the  fourth  phase  of 
clock  "bus_clock". 

Alternatively,  a  control  clause  may  take  the  form  of  a  list  of  nets 
that  the  component  Is  to  be  sensitised  to.  This  format  is  called  a 
"check  list",  because  whenever  one  of  the  nets  mentioned  in  it  is 
updeted.  the  booleen  expression  is  rechecked.  By  this  means,  it  is  easy 
and  efficient  to  describe  asynchronous  machines  driven  by  the  the  nets 
to  which  they  are  connected.  For  example: 

UAITFOR  data_rdy  *  1  CHECK  data.rdy 


This  statement  would  put  the  component  Into  a  passive  state  until  the 
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"•*  "d«t*_rdy"  wn  updated  to  t ha  value  I .  Ho  simulation  resource*  are 
comumd  while  the  component  it  idle  (there  it  no  "busy  waiting**).  In 
particular.  It  other  component*  ASSIGN  to  data_rdy  whatever  value  that 
it  already  contain*,  the  enpre««ion  "dal  a_rdy  =  I**  I*  not  reevaluated. 
Thi*  i*  because  SABLE  au t omat i cal  I y  delete*  all  »uch  null  update*. 


1.2. 2. 3  Sen* i t ire.  Desensitize,  and  Detach 

Taken  collectively,  these  provide  a  facility  for  direct  control  of 
the  operation  of  a  component.  They  operate  in  a  way  that  I*  similar  to 
MAITFOR.  but  at  a  lower  level  and  somewltet  more  efficiently.  Sensitize 
and  de.*en*itize  are  predefined  procedure*  make  a  component  receptive  or 
immune  to  change*  on  It*  inward  net*.  These  procedure*  are  alway*  used 
in  conjunction  with  the  DETACH  operator,  which  cause*  execut ion  of  a 
component  to  stop  until  one  or  more  of  the  net*  to  which  it  i*  sensitive 
i*  updated.  Uhen  an  update  on  a  sensitized  net  occurs,  the  component 
will  be  awakened. 

Because  of  the  flexibility  of  the  UAITFOR  construct.  it  is 
difficult  to  think  of  on  application  where  DETACH  is  really  more 
convenient,  and  not  merely  more  efficient.  However,  to  Illustrate  It* 
use.  we  (iml I  use  It  to  describe  a  finite  state  machine  that  recognizes 
the  bit  strings  consisting  of  t*s  and  C*s.  The  strings  must  match  a 
regular  expression  that  begins  and  ends  with  t.  and  where  any  0  must  be 
proceeded  and  followed  by  at  least  one  I  (example  taken  from  (KZ70 )  > . 
This  machine  is  stimulated  by  a  net  called  "input..! Ine".  which  contain* 
a  dote  element  "d"  and  a  strobe  field  "s".  (In  order  to  drive  this 
machine.  it  is  necessary  to  put  the  data  value  In  the  **d"  field,  and  to 
update  the  "***  field.)  In  ADLIB,  one  way  to  define  the  automaton  1st 
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sen* i t i  set input _l in#) ; 

1«  dttichi  (•initial  state*) 

it  input_lin*.d  •  0  than  goto  Si 

Zs  ^accepting  state*) 

wr it #ln< output . 'accept • ) i 
detach; 

it  input_lin*.d  -  0  than  goto  ti 
goto  ?i 

Si  datachi  (•  terminal  state*) 
goto  Si 

Whan  combined  with  t h«  facilities  available  in  PASCAL.  t  h*  above 
primitive*  are  adequate  to  encode  almost  any  conceivable  function  among 
a  component* *  net*.  However,  before  a  design  language  will  be  used,  it 
must  be  more  t han  adequate,  it  must  b*  convenient.  Theretor*  ADLIB  also 
incorporate*  the  concept  of  "subprocesses"  to  facilitate  encoding  the 
behavior  of  many  common  computer  activities.  Each  subprocess  performs  a 
single  function  and  run*  t ndependen t I y  of  the  main  body  of  the  comptype. 
There  are  two  type*  of  subprocesses.  upon  and  transmit. 


I.Z.Z.*  UPON  (boolean  *«pr>  (check  lisl>  DO  <*tmt> 


Upon  is  used  to  define  a  set  of  activities  to  be  performed 
independent ly  of  t h*  main  activities  of  the  component.  Whenever  a  net 
in  (check  li*t>  i*  updated,  (boolean  *«pr>  is  reevaluated.  If  it  is 
true,  then  (stmt)  is  executed.  For  example! 


interrupt  t  UPON  ( int *r r upt . pr i or i t y  >  current) 

CHECK  interrupt  DO 
BEGIN 

push(m*chln*_*t ate): 
serv ic*_ int  *r rupt l 
poptmechin*  state); 

EMDi 

This  cod*  would  check  the  priority  level  whenever  the  interrupt  net 
was  updated,  and  service  the  interrupt  when  necessary. 
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1.2. 2. 5  TRANSMIT  <««pr>  TO  <net>  <t  tmnij  clause) 

TRANSMIT  i*  *10  r  a  specialized  than  UPON.  A  Transmit  tubprocsit 
reevaluates  <a«pr)  whanavar  on#  or  mo r#  of  t he  nat t  in  <n#t  list>  it 
changed.  T  h*  result  is  than  assignad  to  <nat  n#m*>  at  tha  t ima 
tpacifiad  by  <timing  clause).  Transmit  it  vary  convaniant  for 
describing  combinational  circuitry.  For  example,  a  simple  NAND  gate  can 
be  described  with: 

nand: TRANSM1 T  NOT ( a  AND  b>  TO  c  CHECK  a.b  DELAY  ISO; 


1.2  2.4  Inhibit  And  Permit 

The  nem*  given  to  a  tubprocatt  m#y  be  used  to  control  it  by  moans 
of  the  procedures  "permit"  and  "inhibit".  All  tubprocassat  era 
initially  inhibited,  which  means  that  no  external  stimulus  can  activate 
them.  The  main  body  of  a  component  may  then  permit  some  or  all  of  the 
subprocessas  to  run.  at  which  point  they  are  ready  to  respond  to 
stimuli.  Subprocessas  may  be  inhibited  at  any  time,  which  return*  them 
to  their  initial,  inactive  state.  For  example,  a  computer  may  protect  a 
critical  region  with: 

inhibit! interrupt 1 J 
write  to(shar#d_date); 
permit! interrupt  >; 

!.J  DESIGNING  AN  ADLIB  PROGRAM 

To  Illustrate  how  ADLIB  is  used,  w*  shall  "design"  a  small  system 
that  plays  Blackjack  with  Itself.  This  was  inspired  by  a  DDL  design 
found  in  ( DDL  7  S I .  but  is  somewhat  more  complex  end  complete.  The  ADLIB 
system  consist*  of  on#  or  more  dealers  end  on#  or  more  players.  Net* 
shall  be  used  to  represent  t h#  flow  of  card*  from  the  dealers  to  the 
player*,  and  to  coordinate  their  activities.  To  begin  our  design 


1 


BASICS  OF  ADLIB  Pago  1-12 

DESIGNING  AN  ADLIB  PROGRAM 


procat*,  we  first  consider  what  data  aiust  ba  t  rant*  j  1 1  ad  (suit  and  rank) 
and  what  control  informat ion  it  naadad  (player  it  wailing  tor  card, 
daalar  it  waiting  for  playar,  ate.)  Wa  davalop  three  typaa  of  natt 
<  nat  t  VP»* t )  that  dafina  the  ttructura  of  t ba  nat *  which  carry 
information  batwaan  component t .  and  aitociata  an  i n t erpr at  at i on  with 
than.  Tha  design  at  thi*  point  might  ba  encoded  at  thown  in  figure  2. 
The  nettypet  thown  fall  into  two  categories!  structured  nettypes,  such 
a*  "cerd_bus"  and  timple  ones.  such  at  "d I  tpl ay_!  i ght  s"  and 
"eont ro l_l ine" .  Structured  nettypet  are  most  utaful  whan  teveral  pieces 
of  information  art  logically  affiliated  but  need  to  ba  updated  and 
examined  independently. 


PROGRAM  cerdgeme; 

TYPE 

tu>t_typa  -  ( c I ubt . hear t s . d i amonds . spades ) ; 
rank  type  •  (ace. two. three. four , f iva. tlx. tavan. 
a i ght . n ina . t  an . jack .quean . k ing)  i 

NETTYPE 

card_bus  ~  RECORD 
suit  .•  suit_typas 
rank  !  rank  typo; 

END) 

di *p!ey_l ight t  =  ( hi t , st and. broke )  : 
control_line  s  t card_rdy . card.accapt ad) ; 

COMPTYPE  dealer;  (•  deals  out  cards*) 

BEGIN 

(•  not  yet  designed*) 

END; 

COMPTYPE  player;  ('accepts  cards,  stands  or  goes  broke*) 

BEGIN 

t*  not  yet  designed*) 

END; 

BEGIN 

END. 

Figura  2  -  Outline  of  Blackjack  System 

Tha  coda  in  figura  2  specifies  thraa  nettypet  but  no  control 
protocol.  Wo  decide  to  use  one  control  line  between  each  playar  and  the 
dealer  that  serves  11.  and  to  alternate  the  value  of  thi*  net  between 
"cerd_rd\'M  and  "car d_accept ed" .  The  synchronisation  mechanism  can  than 
be  expressed  by  the  code  fragments  shown  in  figure  J.  The  first  weitfor 
statement  shown  cautes  the  player  to  wait  until  the  card  is  ready,  and 
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1b*  ••cond  cause*  tb*  deal *r  to  wail  unlit  the  playar  ha*  decided  what 
to  do . 


(*  player'*  cod*  •  ) 

WAITFOR  cntrl  =  cardrdy  CHECK  entrlj 
( •  accept  card*) 

ASSIGN  card_accapted  TO  cntrl  t 
(•  proc**t  card,  go  broke,  hit  or  stand*) 

(*  dealer'*  cod*  •) 

(•  generate  next  card  •) 

(*  assign  nexteard  to  cardbus  *) 

ASSIGN  c*rd_rdy  TO# 

WAITFOR  cntrl  s  cardaccepted  CHECK  cntrls 

Figure  3  Code  fragment*  for  Coordination 


W*  are  now  ready  to  specify  t be  algorithms  used  by  t he  players  and 
dealers.  For  t he  purpose  of  this  discussion,  th*  player  just  accepts 
cards  until  it  reach**  Its  limit,  treating  aces  as  1  or  11  points  as 
needed.  Th*  ADI  I B  cod*  for  th*  player  is  shown  in  figure  4,  and  will  be 
referred  to  later. 
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COMPTYPE  p 1 ayer ; 

(•  declare  t  h*  " t «r* t nal *"  of  this  component*) 
INWARD 

cord  :  card  bus: 

OUTWARD 

light*  i  display_l i  ght  * ; 

EXTERNAL 

C  n  t  r  |  i  cont r o I _1 i n* ; 

(■declare  t  ha  itornqa  naadad  by  this  component*) 
VAR 

•cert  t  0  .  .27; 
holding  aca  !  boolean; 

BEGIN 

WHILE  true  DO  BEGIN 
holdinp_ace  t*  false: 

•  core  s  *  0 ; 

REPEAT 

REPEAT 

ASSIGN  hit  TO  light*) 

ASSIGN  cerd.accept ad  TO  cntrl; 
WAITFOR  cntrl -card  rdy  CHECK  cntrlJ 
IF  card.rank  <  Jack  THEN  score  i* 

score  ♦  ord(card. rank )  ♦  1 
("ord  return*  an  integer  in  0..1J*) 
ELSE  score  ;*  score  ♦  10; 

IF  (card. rank^aca)  AND 
(NOT  holding  aca) 

THEN  SEGIN 

score  i*  score  ♦  10; 
ho  1 d i ng_aca : 5  t  rue  END; 

UNTIL  score  >s  upper  limit; 

IF  (score  >  21)  AND  ho  1 d i ngace  THEN  BEGIN 
score  :*  score  -  10; 
ho  I d i ng_ece  i*  false  END; 

UNTIL  score  >s  upper  limit; 

IF  score  <*  21  THEN  ASSIGN  stand  TO  light* 

ELSE  ASSIGN  broke  TO  lights; 

END; 

END; 

Figure  4:  Definition  of  Cowptype  "Player" 


In  order  to  see  if  comptype  "player"  works  properly.  It  is 
necessary  to  develop  a  "dealer"  comptype  to  drive  it.  There  are  several 
possible  ways  to  do  this,  Just  as  there  are  several  way'*  to  test  a  new 
piece  of  hardware.  In  ADLIB,  It  is  easy  to  write  a  comptype  that  talks 
with  the  terminal  for  interactive  testing.  Another  possibility  is  to 
us*  a  pseudo-random  number  generator  that  will  choose  card*  from  an 
infinite  deck.  A  package  of  such  generator  routines  called  RNDPAK  is 
available  to  ADLIB  users.  Finally,  the  designer  can  writ*  a  comptype 
that  reads  the  test  data  from  a  file.  Each  of  these  approaches  have 
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their  own  merits  at  different  phases  in  the  design  process.  Normally, 
interactive  testing  would  be  used  for  initiol  debugging.  large  numbers 
of  rendem  inputs  for  extensive  testing.  and  prerecorded,  specially 
selected  veKes  for  production. 

Having  specified  the  behavior  of  comptype  "player"  end  "dealer",  we 
are  free  to  use  as  many  of  each  as  we  wish  in  our  design.  The  structure 


CHAPTER  2 

TYPES.  METTYPES  AND  TYPE  CHECKING 


2.1  WHAT  DOES  -STRONGLY  TYPED"  MEANT 

Lika  it*  basa  languaga  PASCAL.  ADLIB  is  said  to  ba  a  "strongly 

typad"  languaga  I0EI7S).  This  aiaans  that  aach  piaca  of  data,  aach 

function  and  all  paramatars  must  aach  ba  daclarad  with  axactly  ona  typa. 
Uhanavar  a  variabla  or  nat  is  usad.  its  usa  must  ba  typa  compatibla  with 
its  daclaration.  In  a  wall-writtan  program.  t ha  typa  of  a  variabla 
dafinas  t ha  narrowast  possibla  ranga  of  valuas  that  it  may  attain. 
Whila  baginning  programmars  may  think  that  typa  chocking  is  an  arbitrary 
ras  t  r i c t  ton  on  thair  programming  styla.  mora  axpariancad  dasignars  can 
usually  put  it  to  vary  good  usa.  Typing  Is  assantially  a  way  for  t ha 
dastgnar  to  axprass  his  or  har  intantions  about  t ha  way  in  which  a  piaca 
of  data  should  ba  usad.  Tha  compilar  can  t han  automatically  datact  whan 
thosa  intantions  ara  violatad.  which  usually  impl las  an  arror.  In 

1 anguagas  that  ara  not  typaful.  it  is  oftan  aasy  to  traat  char actor 

strings  as  roals.  or  intagars  as  polntars.  Evan  whan  this  is  dona 
infant  tonal ly.  it  is  vary  difficult  to  road,  undarstand  and  maintain  tha 
rasulttng  program.  And  whan  it  is  dona  un i nt an t i onal ly •  chaos  can 
rasult.  For  a  discussion  of  PASCAL  typing  and  program  ral lability  tha 
raadar  is  rafarrad  to  IMN731. 

2.2  TYPE  CHECKING  OF  NETS 


Tha  primary  typa  chocking  mac Han  ism  in  ADLIB  to  tha  usa  of  nattypas 
for  da* in Ing  tha  Intandad  intarconnact ion  machanism  batwaan  componants. 
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In  SABLE,  t he  nets  that  connect  component s  must  be  declared  with 
identical  nettypes  at  each  end.  It  this  is  not  so.  an  error  message  is 
printed*.  This  nettype  checking  is  considerably  more  thorough  than 
checks  found  in  most  register  transfer  language's  (RTl's).  where  it  is 
only  necessary  that  the  number  of  bits  must  match.  To  illustrate  this 
difference.  consider  a  component  that  produces  two  BCD  (binary  coded 
decimal)  digits  and  another  that  accepts  eight  bits  of  binary  data. 
Most  RTl's  would  allow  them  to  be  directly  connected,  since  8  bits  =  8 
bits.  Even  simulation  might  not  detect  this  error  if  the  test  set  did 
not  happen  to  include  any  values  greater  than  9.  But  the  ADLIB  -  SABLE 
environment  would  detect  the  mismatch,  since  "BCD*'  is  not  type 
compatible  with  "binary".  Further  examples  of  type  checks  will  be  given 
later  in  this  section. 

But  types  should  not  be  viewed  just  as  a  restriction.  Compared 
with  other  languages,  ADLIB  (like  PASCAL)  offers  a  wealth  of  useful  new 
types  to  choose  from.  The  next  section  illustrates  a  few  of  the  ways 
that  a  designer  can  take  advantage  of  them  to  -educe  errors  and  improve 
readabi I ity . 

2.3  DATA  TYPES  AVAILABLE  IN  ADLIB 

Because  ADLIB  is  a  superset  of  PASCAL,  it  inherits  all  of  the 
PASCAL  type  construction  mechanisms.  For  the  benefit  of  readers  not 
familiar  with  PASCAL,  these  are  listed  here: 


•Unless  a  special  TRANSLATOR  has  been  provided.  TRANSLATORS  provide  the 
ability  to  do  multi-level  simulation  at  the  expense  of  some 
t vpe-check ing  security  end  some  loss  of  data  precision.  For  a 
discussion  of  their  use,  see  ( H DO 79-11 . 
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2-5.1  Boo  1 ean 

Boo  I ean  variables  con  attain  the  values  true  or  falsa.  (Siailar  to 
FORTRAN'S  LOGICAL.)  For  example  if  "stroba"  wars  daclarad  to  ba  of  typa 
boolaan  we  could  write> 

stroba  i *  data_rdy  AND  (bus.clock  -  5) 


2.5.2  Integer 

I .a.  -15.  or  I  02* . 


2.5.5  Raal 

l.a.  5.  UtSO  or  t.023e?A 


2. 5. A  Enumerated  Typas 

Thaaa  allow  a  usar  to  enumerate  (list  out)  all  the  possibla  valuas 
of  a  piaca  of  data.  For  example: 

logic_laval  *  (low.  high,  unknown,  hi gh_ inptdanca ) 

Ua  have  already  seen  savaral  examples  of  enumerated  typas  in  t He 
cardgrme  program.  Enumerated  typas  ara  also  usaful  for  dascribing  t ha 
instruction  sets  of  machines,  such  as  the  INTEL  BOOB  f  X  7  S 1 z 


TYPE 

instruct.k ind  -  ( I rr , 1  re, l*r , l r i , 1ml , 
inr ,dcr .edr.edn.  (Rate*)  )i 

In  ADLIB,  one  can  usa  a  CASE  statement  to  dascriba  tha  execution  of 
a  machine  instruction  in  a  format  vary  siailar  to  ISP  (BCG7I).  For 
example: 
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FUNCTION  decode  i  inst ruct _k  ind; 

(•  coda  omitted  Tor  brevity") 

BEGIN  (•mam  body  o*  program*) 

CASE  daeoda  OF 

Irr  i  (•  toad  rag  to  reg«) 

BEGIN  (•  coda  omitted  ■)  END; 
rat  i  (•  rat  urn  from  lubrout ina1) 

BEGIN  (•  coda  omittad*)  END; 

( •ate*) 

END; 


2.1.)  Subrange* 

These  specify  that  only  part  ot  a  range  of  value*  ia  accaptabla. 
for  taonplai 


regi »t er_numb*r  *  0..7 

specifies  not  only  that  variable*  of  typa  ra9 i at er_numb*r  ara  integer*, 
but  also  that  they  must  lie  between  0  and  7  (inclusive).  Assigning  a 
value  to  a  subrange  variable  that  i*  outside  its  range  is  aut omat ice! ly 
detected.  For  example.  in  the  ADLIB  blackjack  machine  the  variable 
"score'*  uas  declared  to  range  over  the  values  0  to  27,  the  high  value 
being  eoual  to  I*  (the  highest  possible  score  before  standing)  ♦  II 
(value  of  an  ace).  By  contrast,  the  DDL  version  merely  declared  the 
score  to  be  a  five  bit  register.  The  ADLIB  approach  has  two  advantages. 
First,  it  allows  the  designer  to  defer  any  decision  on  the 
representet ion  o*  data  in  the  early  stages  of  design.  Second,  and  more 
importantly,  it  encodes  more  information!  e.g.  the  fact  that  the  score 
can  never  evceed  27.  Although  this  is  not  too  critical  hare,  it  is  easy 
to  visualise  applications  where  the  range  of  data  that  a  register  holds, 
if  known.  can  be  used  to  improve  the  design.  For  example,  nine  ADLIB 
blackjack  scores  could  safely  be  added  in  an  8-bit  alu,  since  we  know 
the  total  cannot  exceed  2*3.  On  a  more  practical  level.  It  might  be 
useful  to  know  not  only  that  memory  addresses  in  a  DEC  ID  are  18  bits 
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»or>9.  but  alto  that  t  hay  rang*  Iroa  16  to  262166,  (fine*  t  ha  flrat  16 
eddr*****  r»t»r  to  regiatara). 


2.5.6  Array* 

AKKAY  |«  alailer  to  DIMENSION  In  FORTRAN .  For  example: 

memory  s  ARRAYIO. . 10231  OF  lnt*9ar 

2.S.J  Record* 

Record*  ara  uaaful  for  grouping  ralatad  data,  aa  for  example; 

complex  •  RECORD 

r**l_pert . i**g_p*rt  t  raall 
ENDi 

Moat  r ag i at  *r  tranafar  languaga*.  Including  DDL.  prowlda  nachani*** 
for  making  aavoral  naan  equivalent  rafarancaa  to  t ha  aaa*  placa  of 
data  Tha  uaual  example  of  thla  I*  an  Inatructlon  raglatar.  where  on* 
of  th*  blta  la  glvan  «  antronlc  nam*  auch  aa  "I"  (for  Indirect)  In 
addition  to  baing  IR10I.  Thla  can  make  parta  of  a  progrm  nor* 

raadsbla.  but  can  alao  lead  to  contuaion  whan  a  mnemonic  la  referenced 
for  the  flrat  tin*  severe)  pagoa  away  fro*  Ita  declaration.  Th* 
atratagy  adopted  by  ADLIB  la  to  uae  "variant"  racorda  for  thla  purpoa*. 
A  variant  record  la  eaaenf  tally  a  aingl*  data  area  that  may  Nave  aavarat 
different  data  atructur*  "template*"  applied  to  it.  Aa  an  example  of 
thla,  conaider  th*  four  may*  that  on*  can  look  at  an  HP  2116 

Inatructlon,  a*  dlacuaaed  In  t Ha  machine  manual  |HP|  In  ADLIB,  thaa* 
alternative  view*  would  be  encoded  aa: 
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TYPE 

instr_varient  s  ( who  1 e. memory  ref, register  ref. I  o)» 

VAR 

tr  :  RECORD  CASE  in»tr  variant  OF 

Whole  :  (ARRAY!?.  . 151  OF  bit)j 
memory  ref  i  (  indirect  i  bitl 

mem_lnstr  i  ARRAYIO.. 4|  OF  bits 
zero  >  bits 

mem_addr  i  ARRAYIO  *|  OF  bit)! 
reg  ref  s  (group  i  ARRAYIO. .31  OF  bits 
micro  i  ARRAYIO.  Ill  OF  bids 
i_o  :  ( io  group  :  ARRAYIO.  .51  OF  bits 
io  inetr  t  ARRAYIO. 51  OF  bits 
select  s  ARRAYIO. .51  OF  bits 

ENDS 

This  record  informs  the  reader  (and  the  compiler)  thet  the 

instruction  register  "tr"  may  be  viewed  in  four  different  ways,  but  is 

still  in  fact  Just  one  register  14  bits  long.  (Note  that  the  total 

number  of  bits  in  each  variant  is  14.)  Access  to  ir  can  then  be 

performed  using  the  mnemonic  fields,  as  tor  example' 


ir. whole  s •  data_buss 
or 

IF  ir. indirect  :  t  THEN  cycle  s*  fetch; 


Now  t  lie  fields  are  closely  associated  with  the  register,  end  the  reader 
is  (hopefully)  less  likely  to  misinterpret  them. 


2.J.8  Sets 

A  SET  is  an  area  of  storage  that  may  contain  from  0  to  all  of  its 
members  i.e.  a  power  set .  Textual ly.  sets  are  delimited  by  "I*  and  "1". 
and  faeilties  are  provided  for  set  intersection  (AND).  union  (OR), 
difference  (-)  membership  (IN),  equality  ("*").  size  comparison  ("<"  and 
">").  Since  sets  ere  normally  packed  Into  machine  words,  these 
ooerat ions  usually  run  very  quickly.  Sets  are  convenient  for  grouping 
related  symbols.  both  visually  for  the  reader  and  logically  for 
simulation.  For  example,  in  the  BOOB  we  can  express  certain  facts  in 
machine  readable  form  that  are  normally  only  shown  on  the  date  sheets. 
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luch  at: 

i  nd#*_ inst  rue t  *  i  *  tl  rr  >  1  r*.  Imr ,  1  r  I .  la  I ,  I  nr .  dcr )  I 
°n»_eycl*_ali»s  *  ladr .  »cr.  »ur,  ibr,  ndr ,  «rr ,  orr  .  cpr  |  ; 

A*  an  example  of  th*  us*  of  set  operators.  consider  Lh#  coda  that 
describe*  th*  timing  of  part  of  tha  axecut  ion  cyclo.  It  might  contain: 

IF  instruction  IN  on*  cyct*  alu  THEN 
UAITFOH  SYNC  FHASE  Ti 


2.3.S  F i | at 

Th*  ADLIB  vitar  may  dactara  various  typas  of  FILE*  to  Batch  t  h*  data 
to  b*  stored  in  than.  Storing  and  ratriaving  that  data  can  than  b* 
eccompl i shad  vary  efficiently.  For  example,  it  is  easy  to  describe  a 
cor*  image  at: 


cor*_i»ag*  i  FILE  OF  integer: 

For  convenience,  special  facilties  ara  provided  for  reading  »n(j  writing 
file*  of  text . 

2 . S . 1 0  Po int  er * 

PASCAL,  (and  therefor*  ADLIB)  provides  two  independent  areas  for 
storing  data,  th*  ordinary  stack  and  a  heap.  Th*  heap  is  accessed  only 
via  special  pointer  variables.  which  may  in  turn  point  to  other 
pointers.  etc.  This  makes  it  convenient  and  efficient  to  develop 
co-olav  data  structures.  Pointers  *r*  denoted  by  t h#  up  arrow  "t".  For 
example.  t  he  data  structures  for  describing  a  virtual  memory  system 
might  look  I ike: 
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TYPE 

pogo  »  ARRAY  10.  .311)  OF  tntogori 
pogo_ptr  *  'pogo:  (•  "t*  moon*  "pointor  to"B) 
po<jo  tnblo  *  ARRAY  10  . 2551  OF  RECORD 
legicol.oddrott  i  0. 6*235; 

<*_tncoro  i  bool  Mn  i 
r»omory_rof  «  pogo_.pt  r; 

END! 

Now  olomontt  art  oddod  to  t ho  hoop  by  moon*  of  t ho  "now"  procoduro. 
Uting  this,  port  of  t  ho  codo  to  dotcribo  aioatory  monogomont  anght  bo 
wr  1 1 1  on ; 


VAR  pn  i  pogtnop l 

O  4 

IF  NOT  pa|high_bitt) . tt_lncoro  THEN  nowt p*t . »»»ory_r#( > ; 

Thi*  would  ollocoto  o  now  pogo  of  aooory  frow  t ho  hoop  if  t ho 
"  I »_  incoro"  flog  of  pogo.mop  "pa*"  woro  folto. 

Mhoroot  tho  obovo  typo*  oro  port  of  both  PASCAL  and  ADLIB.  t ho 
following  two  oro  ovoiloblo  only  in  ADLIB. 

2.3.11  Bit 

Thi*  it  o  prodoclorod  tubrongo  of  tntogor.  It  a*oy  rongo  ovor  tho 


vo I uot  0 . . I . 
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2. S. 12  Register 

Thia  li  a  pradaclarad  type  that  it  useful  for  RTl  daierlpt lent. 
Many  special  routines  ara  provided  for  aan ipulet ing  war iables  of  typo 
register,  such  aa  exclusive  or.  rotata.  ate.  Arithmetic  way  ba 
par formed  on  registers  in  ona'a  complement.  two's  complement .  aign 
magnitude.  and  unsigned  foraata. 


2.3.13  Another  Exemplet  R5232  Interface 


On*  can  combine  enumerated  typaa  with  racorda  to  Croat*  a  vary 
atrong,  aptclfic  definition  of  an  interface.  For  example,  conaidar  th* 
RS232  connact ton  atandard.  float  RTL'a  Mould  aaraly  apacify  it  aa  a  23 
bit  connaction,  which  could  b*  written  in  ADLIB  aat 


RS232  «  ARRAY  ft. .251  OF  bit: 


Howavar.  thia  would  not  make  boat  ua*  of  th*  facilities  available.  In 
ADLIB,  it  would  b*  batter  to  writ*! 


TYPE 

widarang#  s  (nag  1 2V . poa_l2V ) i 

grounded  *  (xaroTi 

NETTYPE 

RS232  *  RECORD 

fg  i  grounded!  (•frame  ground*) 
td  i  widarang*:  (•transmit  data*) 
r d  i  widarang#:  (•received  data*) 
rta  s  widarang#:  (•  request  to  sand*) 

(•  *tc.«) 

END! 

It  th#  not  ** 1 1 y  1  _ I  in*"  war*  declared  to  b*  of  nattyp*  RS232.  than  th* 
compiler  would  accept 


ASSIGN  n*g_12V  TO  t t y 1_1 in* . t di 


but  would  flag  a*  an  error i 


ASSIGN  B  TO  t tyt_l in*. t*rminel_rdy ; 


CHAPTER  J 

A  CONTOUR  MODEL  FOR  ADLIB 


Th#  chapter  it  lottndtd  to  be  in  informal  but  unmbifuouo 
definition  of  the  behavior  of  systems  tpocifiod  in  ADLIB  end  SCI.  end 
simulated  under  SABLE.  The  definition  contittt  of  three  pertt:  e 
ttetic  contour  model  for  ADLIB  programs.  a  dynamic  contour  model  for 
their  execution  under  SABLE,  and  a  simulation  structure  that  defines  the 
the  various  ADLIB  primitives.  For  readers  unfamiliar  with  contour 
models,  an  introductory  tutorial  is  available  in  IJBJ71).  Also  of 
interest  is  SIMULA  Begin  IBGM7J)  which  is  tuned  to  SIMULA67.  and  OREGANO 
t  B  D  7 1 ) .  However,  the  basic  principles  of  contour  models  ere  fairly 
slmole.  and  this  description  will  avoid  the  more  complex  issues. 

5. I  CONTOUR  MODELS 

A  contour  model  uses  rectangles  to  represent  scopes  of  program 
identifiers  as  defined  by  the  user.  A  static  contour  model  represents 
the  wey  in  which  those  scopes  are  nested  in  the  source  program.  eg 
proctdufis  within  procedures.  global  and  local  variables  etc.  Such  a 
drawing  can  be  used  to  answer  auestions  about  identifier  visibility, 
naming  conflicts.  and  data  hiding.  The  set  of  identifiers  visible  at 
any  point  In  the  model  is  determined  by  examining  each  enclosing  contour 
in  turn  Identifiers  inside  of  non-nested  contours  can  be  accessed  only 
through  "access  pointers"  (ep*s)  that  link  one  scope  with  another. 
Access  pointers  are  used  extensively  in  SIMULA  *7  to  perform  a  "remote 


A  CONTOUR  MODEL  FOR  ADLIB 
CONTOUR  MODELS 


P«9*  5*2 


•cc»i»,"  which  it  whiri  on*  proem  r**ch*s  into  another  and  may 
dir*ctly  altar  intarnal  attributes  of  it.  This  facility  is  not 
available  to  t ha  ADLIB  user  diractly  Dacauia  it  invites  hard-t o-dat act 
side  effects  and  bad  coda  structuring. 


S.2  STRUCTURE  OF  AN  ADLIB  PROGRAM 

Th*  static  contour  modal  for  an  ADLIB  program  it  illustrated  in 
figure  I. 


5.2.1  Globa)  Identifiers 

Th*  modal  shown  in  figure  I  it  not  much  different  from  t ha  contour 
model  of  a  PASCAL  program.  In  t ha  upper  left  hand  corner  of  each 
rectangle  appear  the  user  defined  labels,  constants,  and  types  and  also 
the  user  declared  variables*.  In  addition,  more  rectangles  may  appear 
within  a  rectangle  representing  nested  scopes. 

In  th*  outermost  contour  is  t h*  pradac I ar*d  variable  "t im*"  which 
represent*  the  simulation  time.  User  assignment  to  this  variable  is 
illegal  and  it  detected  at  during  compilation.  Contour  2  in  figure  1  is 
th*  global  level  for  t  he  user.  In  it  are  found  t he  user's  global 
labels,  constants,  types,  nettypes  clocks.  variables.  rout  in****  and 
comptypes.  The  meanings  of  label*,  constant  end  type  definitions,  are 
unchanged  from  PASCAL.  There  is  also  an  algorithm  associated  with  this 

A 

•In  this  report,  item*  t h»t  do  not  consume  storage  at  runtime  are  said 
to  be  "defined",  end  items  that  do  are  said  to  be  "declared".  In 
particular,  item*  that  are  defined  do  not  appear  inside  of  contours  in 
th*  dynamic  models. 

••Throughout  this  paper,  t h*  word  "routine"  is  taken  to  mean  procedure 

or  funct ion. 
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contour  that  could  b.  called  the  "wain  body"  of  t h.  program  which  can  b. 
used  for  initialization  of  th.  global  variables.  r. sotting  files  and 
such.  This  main  body  may  not  contain  any  ADLIB  control  primitives  such 
as  detach  or  waitfor,  and  may  not  access  any  component  or  net.  During 
the  execution  of  the  program's  main  body*  time  and  all  clocks  are 
identically  zero.  This  code  block  may  call  global  routines  that  call 
further  routines  recursively,  just  like  the  main  body  of  an  ordinary 
PASCAL  program. 

The  fnclusion  of  global  variables  into  ADLIB  is  a  concession  to 
practicality  and  user  convenience.  Ideally,  a  design  should  not  have 
any.  since  they  might  represent  inter-  component  connections  that  have 
no  physical  correspondence .  However,  there  are  also  many  applications 
for  global  variables  that  do  not  violate  the  intended  structure  of 
SABLE.  For  example.  data  collection  and  i n t erpr et at i on  can  be 
simplified  if  each  component  calls  a  routine  that  accepts  intermediate 
results  and  stores  them  away  in  a  global  area  for  later  analysis.  On 
the  other  hand,  global  variables  should  not  be  used  for  intercomponent 
commun i cat i on .  This  is  what  nets  are  intended  for,  just  as  parameters 
are  intended  for  communicating  with  routines.  It  may  be  possible  to 
detect  such  clandestine  component  interaction  during  compilation  and 
prohibit  it.  just  as  there  have  been  proposals  to  ensure  that  routines 
have  no  side  effects.  However,  such  mechanisms  can  generally  be 
defeated  and  are  invariably  unpopular  with  programmers.  The  decision  of 
how  to  use  global  variables  is  therefore  left  to  the  user. 


3.2.2  Nets  And  N.ttypes 

Nettype  definitions  are  stmilier  to  type  definitions,  except  that 
they  inform  the  compiler  that  it  must  be  prepared  to  handle  nets  of  this 
type.  Nets  are  a  concept  that  is  uniaue  to  ADLIB,  similiar  to  but  not 
the  same  as  ordinary  program  variables.  Nets  are  allocated  in  a 
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different  wav  from  variable*.  and  ar*  interconnected  with  other 
components  and  with  t  h*  simulation  support  *ystam.  Th*  various  nettype* 
thus  datina  tha  ways  that  the  components  ara  abla  to  interact.  Tha 
importance  of  this  for  error  detection  and  varification  is  discussed  in 
IHDD79-IJ.  During  simulation,  the  support  system  generates  new  data 
items  of  the  various  nettype*.  compares  them,  does  assignment*  to  them, 
and  dynamically  regenerates  the  storage  al toted  to  them.  Nettype*  (as 
opposed  to  ordinary  typos)  must  be  used  whenever  nets  ar*  declared 
inside  comptypes  or  are  used  as  paremetirs  to  routines.  Functions  may 
not  return  nets,  and  nets  may  not  appea  on  the  loft  side  of  assignment 
(":s")  statements.  To  update  a  net.  the  ASSIGN  statement  and  the 
TRANSMIT  subprocess  facilities  ar*  provided.  (This  is  somewhat  1  ike 
SIMULA  67.  where  updating  a  pointar  require*  a  special  syntax. )  Any 
expression  assigned  to  or  compared  with  a  not  must  be  type  compatible 
with  th*  nettype  of  the  not.  Within  a  comptyp*.  two  type*  or  nettype* 
are  compatible  if  they  ar*  subranges  of  the  same  base  type****. 

Whenever  a  not  appears  where  an  expression  is  called  for,  t he 
current  value  of  the  net  Is  used.  in  th*  seme  way  that  a  program 
variable  normally  refects  its  value.  When  a  net  is  used  as  t h*  subject 
of  an  assign  or  transmit  statement,  its  reference  value  is  usad.  When  a 
not  is  declared  as  a  var  parameter  to  a  routine  (i.e.  t he  keyword  var 
is  used  in  the  parameter  dec  1 arat ion ) ,  the  routine  may  assign  to  it.  If 
t he  not  is  not  marked  a*  var .  then  th*  routine  may  access,  but  not 
update  th*  value  of  t he  not. 


••••This  is  not  true  in  connections  between  components,  because  SABLE 
consider*  each  nettype  to  be  incompatible  with  all  t he  other  nettype*. 
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3.2.5  Clock! 

Following  t ho  ntltypg  definitions,  an  ADLIB  program  may  contain  ona 
or  more  clock  daf in i t ions .  Those  create  functions  that  map  the 
simulation  time  to  an  unsigned  integer.  Their  syntax  i • : 

CLOCK  <clockneme>  (  <period>  .  <numphases>  )  I  DEFAULT!  ; 

Symbol  leal ly,  the  function  is! 

<c I k name >  " 

C t im*/( <per iod>/<numphases> )  )  MOD  <numphases> 


A  clock  function  may  bo  invoked  anywhere  that  a  variable  integer 
expression  is  allowed.  Clocks  may  also  be  used  in  timing  clauses,  which 
are  explained  in  the  next  section. 


5. 2. A  Timing  Clauses 

Timing  clauses  may  be  used  in  assign,  transmit  and  waitfor 
statements  throughout  an  ADLIB  program.  A  timing  clause  yields  a  time 
value  at  each  evaluation.  This  time  value  is  used  in  various  ways  as 
described  later.  There  are  two  forms  of  timing  clause:  sync  and  delay. 


3.2.A.1  SYNC 

The  syntax  for  a  sync  timing  clause  is: 

SYNC  1  <clock  name>  (PHASE  <int*g*r  phase  number>J 1 
If  <elock  name>  is  omitted  the  clock  marked  "default"  is  used.  If  phase 
is  omitted,  phase  0  is  assumed.  The  value  returned  by  this  sync  timing 
clause  is  t  he  next  time  when  the  specified  clock  will  go  through  the 


■■M—  .—  II 
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specified  phase.  Symbolically,  this  can  ba  writtan  as: 

SYNC  <clecW  nam*>  PHASE  <intag*r  phas*  numbsr)  : : 

min  (  ft  *  t  raal  I  C  t  *  >  tima)  AND 
<c 1 ocknsnsX t * )  -  (integer  phas*  numbtr>) 


3. 2. 6. 2  DELAY 

Tha  othar  timing  expression  usad  in  ADLIB  is  t ha  dalay  clausa  which 


has  tha  syntax: 


This  avaluatas  as: 


DELAY  <raal  dalay  t ima> 


tima  ♦  <raal  dalay  t im*> 


3.2.3  Rout i nos 

Global  routinas  *r*  raprasantad  as  in  PASCAL  and  may  includa  more 
rout inas  nastad  within  thamsalvas.  Thasa  rout inas  may  b*  fraaly  callad 
from  ins>d*  any  comptypa.  and  may  contain  assign  statemants  to  nat 
parameters.  However,  routinas  may  not  contain  waittor  or  datach 


statements.  This  restriction  allows  an  enormous  simplification  and 
acealarat ioh/of  the  runtime  support,  because  it  sharply  reduces  tha  "aod 
for  dynamic  storage  reclamation  ("garbage  collection")  found  in  soma 
simulation  languages.  (for  example  SIMULA  67).  Since  ADLIB  provides 
othar  facilitias  such  as  subprocassas  and  batter  interprocess 
communicat ion,  it  is  hoped  this  restriction  will  not  ba  overly 
constraining. 


3.2.6  Comptypa  Definitions 


Following  t ha  global  routine  definition  section  is  tha  "raison 
d’etre"  for  tha  whole  ADLIB  |»  <yr«n,  tha  component  type  definitions 
(ccmptypes).  These  are  the  only  part  of  an  ADLIB  program  visible  to 
SABLE.  Comptypes  are  similar  to  routine  definitions  in  that  they 
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EXTERNAL  (both  receive  and  IrmwH)  or  INTERNAL  (receive  end  tranpmit 
but  only  within  t h*  component).  It  ip  illegal  to  eppign  or  trenemit  to 
an  inward  net.  or  to  acceps  the  value  of  an  outward  not.  In  addition  it 
ip  illegal  to  lanpitiz*  an  outward  not.  or  to  place  an  outward  net  in  a 
chock  1 i » t .  The  intention  hare  ip  to  anpure  that  information  never 
flow*  froa  a  net  marked  outward  or  to  a  net  marked  inward.  If  both 
torap  of  accepp  are  needed  the  net  phould  be  marked  external. 


1.2.4. J  Internal  Note 


INTERNAL  netp  may  be  examined  and  manipulated  by  a  component  jupt 

like  external  onep.  However,  internal  netp  are  part  of  the  behavior 

ppec  i  f  icat  ion  only,  and  do  not  appear  in  any  etructural  deecnption. 

They  ar*  ueetul  to  help  ppecify  lh*  behavior  of  a  component  with 

inertial  deteyp  or  other  internal  timing  char  act er i pt i c* .  For  example, 

conpider  a  combinational  circuit  that  implement*  the  function  "(a^bl^c" 

by  mean*  of  a  2*input  AND  gate  and  a  2- input  OR  gate.  If  the  exact 

input  to  output  timing  relation  were  important,  an  internal  net  might  be 

u*ed  to  help  code  thi*  circuit'*  behavior.  In  ADLIB,  thi*  could  be  done 

a*  in  F i gure  A . 

COMP TYPE  combins 
INWARD 

a.b.c  !  bool  net  S 

OUTUARD 

d  :  boo  I  net ; 

INTERNAL 
x  i  boolnet; 

SUBPR0CE5S 

andgate  i  TRANSMIT  (a  AND  b)  TO  x  DELAY  TS.Ol 
orgate  i  TRANSMIT  <x  OR  c)  TO  d  DELAY  14.0; 

BEGIN 

perm 1 1 ( andgat  e I : 
permit (orgate); 

END: 


Figure  4 

Combinational  Logict  DC(A*B>*C 
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The  internal  nat  x  represent*  the  intermediate  value  (a*b).  The 
transmit  subprocess  "andgate"  cause*  the  value  of  a*b  to  be  transfarad 
to  net  x  with  a  delay  of  IS  time  units.  The  expression  "a  AND  b"  Is 
reevaluated  whenever  net  a  or  net  b  is  updated.  and  if  a  new  result  is 
obtained  a  net  update  takes  place.  The  "«rg«ts"  subprocess  operates 
asynchronous!'/  so  that  whenever  x  or  c  is  updated,  an  assignment  is  made 
to  net  d.  The  overall  result  is  that  a  change  in  nets  a  or  b  is 
reflected  at  net  d  after  29  time  units,  white  a  change  in  net  c  is 
reflected  after  only  19  time  units. 

tebels.  constants,  types,  verieble*  and  rout ine*  in  comptypes  are 
unchanged  from  PASCAL.  and  again  these  routine*  may  be  nested 
arbitrarily.  Following  the  normal  scoping  rules,  routine*  have  access 
to  all  the  identifiers  inside  the  comptype.  and  to  all  those  defined  at 
the  global  level . 


5.2. 9. 9  Subprocesse* 

The  next  part  of  a  comptype  definition  it  the  subproces* 
declaration  section.  Subprocesse*  are  like  "little  components"  that  run 
autonomously  from  the  main  component  body,  but  under  its  control.  They 
might  be  used.  for  example.  to  describe  the  direct  memory  access 
channel*  in  an  IBM  570.  Their  purpose  <*  to  simplify  the  code  in  the 
main  body  of  the  comptype  by  taking  care  of  secondary  functions. 
Because  the  subprocesse*  are  watching  for  interrupts  and  other  low  level 
activities.  the  the  main  body  of  a  comptype  can  concentrate  on  the  high 
level  supervisory  tasks  of  the  component .  resulting  in  a  less  cluttered 
and  easier  to  read  piece  of  code.  Subprocesse*  are  less  powerful  t  hen 
the  main  body  of  the  comptype  for  two  reasons:  they  execute  a  fixed 
algorithm  to  completion  each  time  they  are  activated,  and  the  criterion 
for  their  activation  is  fixed  at  compile  time,  unlike  the  main  body  of 
the  comptype  which  may  be  stimulated  in  different  ways  at  different 
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points  in  its  execution.  Subprocassas  may  b*  control  lad  by  th* 
pradafinad  procaduras 

inhibit (  <subproc*ss  nama>  ) 
and 

parmitt  Csubprocess  na ma>) 

Th*  formar  disablas  a  subprocass  from  running,  and  t ha  lattar  enables  it 
to  run.  Those  procedure  calls  may  appear  anywhere  inside  a  comptyp* 
definition,  and  do  not  need  to  textual ly  follow  t ha  subprocass  nomad  In 
t  ham . 


3. 2. 6. 5  Th*  Main  Body  Of  A  Comptyp* 

Th*  main  body  of  t h*  comptyp*  describes  t  ha  fundamental  activities 
of  that  type  of  component.  In  addition  to  assigning  new  values  to  nets, 
and  permitting  and  inhibiting  subpr ocas sas .  t he  main  body  may  also  place 
itself  Into  a  wait  state.  wh*r*  it  stays  until  sen*  stimulus  is  received 
or  some  condition  is  met. 

A  complete  and  unambiguous  definition  of  these  and  all  ADLIB 
primitives  in  torms  of  danotat tonal  semantics  will  b*  available  in 
IHDD71-2I . 


CHAPTER  4 
ADLIB  SYNTAX 


Th*»  iu i"'«ry  of  ADLIB  syntax  it  derived  from  t ha  appandicat  of  the 
PASCAL  U»er  * •  Manual  and  Raport  IJK721  .  with  f  ha  additional  ADLIB 
construct*  included  uhtra  nacasiary . 


*. 1  LOW  LEVEL  SYNTAX 

Tha  basic  format  of  ADLIB  proflram  is  patterned  closely  after 
PASCAL.  Heuavar  a  f aw  point*  of  c I ar i f i cat i on  and  difteranea  exist. 

1.  Identifier*  may  include  the  underscore  and  the  u*a  of  upper  or 

lower  ca*e  cheractar*  (*  in* i gn » I icant . 

?.  In  order  to  *horten  the  coda*  reduce  programmer  effort*  and 
eliminate  t r an*cr t pt I  on  error*,  a  u»er  may  "include"  file*  into  hi* 
or  her  ADLIB  isurca.  The  Syntax  t*  (starting  in  column  l)t 

(include  filename 

"Filename"  mU*t  be  a  valid,  unambiguous  file  name.  It  syntax  may 
depend  on  the  operating  system  employed. 

3.  Comment*  are  delimited  by  "(•"  and  "*1"  and  way  be  nested  to  any 
depth.  In  addition,  a  second  comment  convent  ion  i*  supported.  Any 
text  between  an  exclamation  point.  and  the  and  of  a  source  line 

i»  ignored.  Tha  exclamation  point  is  ignored  inside  a  (•  •)  pair, 
end  tha  symbol*  <•  and  *)  are  ignored  between  an  exclamation  point 
end  tha  and  of  a  line.  Tha  following  is  therefore  syntatically 
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correct i 


(•this  comment  it 

9«rb«q»!  not  i  ca  exclamation  is  ignored 
hare  f  •) 

x  s*  •  but  not  Kora,  so  (*  is  inatfactiva 
•7.2  (•  «ora  co"*ant«)  i!  again  is  affactiva 


and  is  syntactically  aquivalant  to: 

x  It  17.2; 

A.  In  ordar  to  pass  though  t ha  p«rsar>  comptypa  namas  and  nat  namas 
rust  ba  valid  ADLIB  idantifiars.  But  this  can  1 aad  to  conflicts 
sinca  dasignars  usually  prafar  to  usa  names  meaningful  to  thair 
application.  For  a««npla>  ona  could  not  dafina  a  comptype  nansd 
"and"  or  a  nat  named  "in"  bacausa  thasa  conflict  with  rasarvad  words. 
To  remedy  this  situation.  ADLIB  allows  a  progra*«ar  to  spacify  a 
sacond  tor  comptypas.  nat  s  and  parameters  to  comptypas.  This 

nora  is  spacifiad  immediately  attar  t  ha  valid  ADLIB  nama  and  is 
anclosad  by  doubla  quotas.  SABLE  will  saa  only  tha  nama  anclosad  in 
quotas.  For  ai**pls: 

comptypa  andgsta  "and"( propdal ay  "dalay"  : 
real ) ; 

inward 

innat  "in"  »  boclnat; 

<•  etc*) 
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4.2  summary  of  operators 

An  attar itk  indicates  thota  that  ara  in  ADLIB,  but  not  PASCAL. 


operator 

optrat ion 

oparand  ratult 

ASSIGN* 

not  aiatgn*ant 

t iaing  clauia 

t  2 

att  <  gnmant 

any  typa 
axcapt  fil* 

ar  i 1  hi»*t  i  c  : 

♦ t  unary) 

idant  tty 

intagar  taaa  at 

or  raal  oparand 

-(unary) 

t i gn  invariion 

♦ 

add i t 1  on 

- 

iubt  ract ion 

• 

aul t ipl icat ion 

dix 

intagar 
diw  i  t  ion 

intagar  intagar 

nodu 1 ut 

intagar 

/ 

raal  divition 

intagar  raal 

or  raal 

ralat ional  : 

: 

aqual i ty 

tcalar .string,  boolean 

<> 

inaqual i ty 

tat  or  pointar 

< 

last  than 

> 

graatar  than 

<* 

!•»«  or  equal 

-or- 

tcalar  or  atring 

tat  inclution 

tat 

>* 

graatar  or 
aqual  -or- 

tcalar  or  tiring 

tat  inclution 

tat 

la 

tat  nambar thip 

logical : 

rot 

na got i on 

boolaan  boolaan 

ar 

d i t  junct i on 

erd 

conjunct  ion 

fot  : 

* 

un  i  on 

any  tat  typa  T  T 

• 

tal  diftaranca 

• 

int  artact i on 
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A. 5  STANDARD  IDENTIFIERS 

The  following  ere  lh«  standard,  pradafinad  idantifiars  in  ADLIB.  A 
user  is  fraa  to  use  redefine  any  of  them#  and  implementors  are  at 
liberty  to  include  additional  predefined  constants.  types.  variables, 
and  routines  wherever  they  might  be  useful.  An  asterisk  indicates  those 
that  are  in  ADLIB,  but  not  PASCAL. 

1 .  Constant  s : 

false,  true,  mavint 

2.  Types: 

bit*,  boolean,  char,  integer,  real,  register*,  tent 

3.  Files: 
input,  output 

A .  Func t i ons : 

abs.  arctan,  chr,  cos.  eof.  eoln,  exp.  In.  odd.  ord.  pred. 
round,  sin,  sqi".  sqrt  ,  succ.  time*,  trunc 

3.  Procedures: 

desensitize*,  detach*,  get.  inhibit*,  new,  pack,  page,  permit*, 
put,  read.  readln,  reset.  rewrite.  sensitize*.  stopsim*. 
unpack,  write,  writeln 
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A. 5  SYNTAX  CHARTS 

That*  c Hart*  were  automatically  drawn  by  a  program  cal  lad  Syndta. 
using  a  BNF-  like  notation  lor  input.  Documentation  on  Syndia  is 
available  in  ICME79-2). 

Field  identt  net  ident.  type  ident.  subprocess  identi  clock 
ident.  net  type  ident >  constant  ident.  and  variable  ident  are  all 
syntactically  equivalent  to  ident. 


SOL  1DCNT 


uhs:cw*o 


UNSICMD  NIJHM* 


ur*s:s*«®_VLT?«» 


S1«*U  £*»"*t*S!C* 


^T^HynayrrB! 


*oct:*<€  tc^iNiTiy^ 


ft  otriMTiom 


APPENDIX  A 

ROUTINE  PACKAGES 


A  major  goal  of  ADLIB  Mat  that  t ha  language  itself  ohould  r amain 
«mat  1  but  ba  easily  extensible  by  t  ha  user  or  impl  ament  or .  This  is  dona 
by  adding  now  data  typas  and  nsw  routinas.  Nota  that  this  doas  not 
imply  any  syntax  changas  or  extensions.  and  doas  not  raguira  t ha  usar  to 
laarn  about  faaturas  not  ralavant  to  his  or  har  own  araa  of  work  (i.a. 
a  usar  can  not  "trip  ovar"  an  axtansion  that  ha  or  sha  was  not  auara 
of  .  > 


In  particular,  two  fairly  larga  packages  of  rout inas  ara  available 
to  t  ha  ADLIB  programmer!  Rgpack.  which  provides  bit  manipulation 
facilities  not  directly  available  in  PASCAL  or  ADLIB;  and  Rndpak,  which 
provides  e  set  of  random  number  generators  with  various  distributions. 
If  the  implementor  did  not  predeclare  them,  than  t ha  usar  must  declare 
them  in  his  or  her  source  program  in  order  to  access  them.  The  easiest 
way  to  do  this  if  with  an  "include"  statement.  I.e.t 

•include  rpaks.dcl 

The  file  "rpefcs.dcl"  is  assumed  to  contain  the  routine  headers  of  all 
the  procedures  and  functions  listed  below.  Nota  that  all  rgpack 
routines  start  with  the  letters  "rg"  and  all  rndpek  routines  start  with 
the  letters  "rnd" .  This  should  help  avoid  naming  conflicts. 
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A. I  RGPACK 

This  sat  of  routines  is  intended  to  be  used  with  PASCAL  end  ADLIB 
progress  tor  describing  t he  bit  manipulation  features  of  computers. 
This  has  the  capability  of  performing  many  common  hardware  manipulations 
not  ordinarily  available  in  higher  level  languages,  such  as  exclusive 
or.  rotate,  etc.  They  make  use  of  the  type  "register"  and  "bit".  both 
of  which  are  type  compatible  to  "integer". 

Register  =  integer 
bit  =  0.  .  I 

There  is  no  difference  between  register  values  and  integers  for 
positive  values.  Negative  values  are  stored  in  the  appropriate  format 
for  the  negative  encoding  selected.  I.e  one  or  two's  complement,  sign 
magnitude.  or  unsigned.  Registers  are  stored  in  one  machine  word  (like 
integers)  and  bits  to  the  left  of  the  most  significant  bit  are  always  0. 

The  routines  are  listed  below  by  class. 

A  .  1 .  I  Initial! sat  ion 

t.  PROCEDURE  rgsetuof least sig,  mostsig.  format  integer); 

Rgsetup  must  be  called  prior  to  calling  any  other  rgpack  routine 
(except  the  i'o  routines).  The  first  two  arguments  specify  the  bit 
number  of  the  least  and  most  significant  bits.  The  third  argument 
specifies  the  ferret  of  negative  numbers. 

two’s  complement  -  0 
one’s  complement  -  t 
sign  magnitude  -  2 
unsigned  -  J 

For  example.  to  describe  en  MP2tHt  computer  one  would  cell 
r gset up( 0 . t S . 0 ) .  Unfortunately,  the  current  imp  1  ament  at i on  supports  no 
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■o than  5A  bit*,  tinea  it  u*a*  ordinary  DECSYSTEM-tO  PASCAL  arithmetic 
opanator*.  and  *u»t  avoid  machine  interrupt*  on  addition. 


A . 1 . 2  Convert i on 

2.  FUNCTION  rgtoregii  i  integer)!  register) 

Rgtoreg  accept*  an  Integer  and  convert*  it  to  register  format 
error  message  will  be  printed  if  i  it  out  of  range. 

5.  FUNCTION  rgtoint (r  »  register)!  integer; 

Kgtoint  converts  a  register  to  integer  format. 


A  .  I  .  3  Arif  hmet i e 

The  following  routines  perform  mo»t  of  the  common  computer 
arifhematic  operations  in  the  various  formats  specified  In  rgsetup.  Two 

of  the  routines,  rgadd  end  rgsub  also  effect  bits  internal  to  rgpack 

itself,  so  that  the  user  can  easily  determine  if  the  last  addition  or 
subtraction  caused  an  overflow  or  carry. 

A.  FUNCTION  rgaddfargl,  *rg2  i  register)  i  register; 

Kgadds  add*  it  two  arguments  end  returns  the  result,  truncated  to 

the  number  of  bits  in  registers.  It  sets  the  overflow  if  the  result  is 

too  big  for  the  number  of  bit*>  and  the  carry  flag  if  there  was  a  carry 
out  of  the  highest  position.  Not*  that  such  a  carry  doe*  not 
necessarily  imply  that  the  result  was  too  large  for  the  specified  word 
size. 

5.  FUNCTION  rgsubfergl,  er gZ  i  register)  i  register; 


iT4W 
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Rg*ub  return*  argl  -  arg2  and  *at*  t ha  overt  low  and  carry  flags. 

6.  FUNCTION  rgovrf low)  bit; 

Rgovrflow  returns  a  one  it  the  overflow  flag  is  sat •  otherwise 

zero. 

7.  FUNCTION  rgcarry:  bits 

Rgcarry  returns  a  on*  if  the  carry  flag  is  sat.  otherwise  zero. 


A. 1.4  Shifts 

8.  FUNCTION  rgshi f t ( source  :  register;  amount  t  integer):  register; 

Rgshift  return*  it*  argument  shifted  the  specified  number  of  bit 
position*.  (Positive  is  toward  most  significant  bit.)  Padding  is  with 
zeros. 

4.  FUNCTION  rgrot at e( source  :  registers  amount  :  integer)  : 

register ; 

Rgrotate  returns  it*  argument  rotated  the  specified  number  of  bit 
position*.  (Positive  i*  toward  most  significant  bit.) 

19.  FUNCTION  rgrot long( source: regi st *r ;  amount : in t eger ;  VAR 

C#rry:bit):r*gist*r; 

Rgrot long  is  similier  to  rgrotate  except  that  #n  extra  bit, 
specified  by  the  user,  is  included  in  t  !■>«  rotation. 

II.  FUNCTION  r gar shi f t ( source  :  register;  amount  :  'nteger): 

regi st  er  t 

Rgarshift  returns  it*  argument  shifted  the  specified  number  of  bit 
position*.  (Positive  is  toward  most  significant  bit.)  The  arithmetic 
Sign  of  negative  numbers  is  extended  in  right  shift*. 
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12.  FUNCTION  rtv|rcnil«**(r«i  :  intagar)  i  intagar; 

bagtn  if  r#i<n»bpoi  than  rat  »*  msbpos  -  I  alaa  If  ras  > 
b«»«word"i  i  nui  1  than  rat  i  *  basawords  I  za  ; 


A.1.S  Bit  Accessing 

•3.  FUNCTION  rgb i t ( r : ragi at ar ;  pot  i  intagar)  i  bits 

Rgbit  raturni  t  ha  bit  locatad  at  position  "pos" ,  ralativa  to  t  ha 
laait  and  «oii  significant  bits  spacifiad  in  satup.  For  example,  if 
mtbnum  =  16  and  1 sbnum  =  1  than  rgbit(t,3)  will  raturn  t ha  third  bit 
from  t ha  right  (Jab)  aids*  which  is  1,  sines  6  is  raprasantad  as 
OOPOOOOCOOOOO  1  1  0  in  binary. 

16.  FUNCTION  rgbitsat(r iragtstarl  pos  i  intagar;  nawval  :  bit)  i 

rag  t  at  ar ; 

Rgbit  sat s  t ha  bit  locatad  at  position  "pos" .  ralativa  to  t ha  Jaast 
and  most  significant  bits  spacifiad  in  satup  to  "nawval"  and  raturns  t ha 
rasul t  . 

13.  FUNCTION  r gf i al d( r i rag i st ar ;  laft. right  t  intagar)  t  ragistar; 

Rgfiald  raturns  tha  bits  locatad  batwaan  position  "laft"  and 
"right",  ralativa  to  tha  laast  and  most  significant  bits  spacifiad  in 
satup.  For  example,  if  nsbnum  =  16  and  I sbnum  r  1  than  rgf i al d( 6 , 6 , 2 ) 
will  raturn  3  (Oil  in  binary.) 

16.  FUNCTION  rgf 1 dsot (r i rag i st ar ;  laft, right  »  Intagar;  nawval  i 

ragistar) iregister ; 

Rgtldsat  sats  tha  bits  locatad  batwaan  and  including  positions 
"laft"  and  "right",  to  "nawval",  and  raturns  tha  rasults. 
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17.  FUNCTION  rgfdrllrg  :  register)  i  integer; 

Rgfdrl  finds  t Ha  rightmost  t  in  a  register,  and  raturm  it*  bit 
position  in  t ha  coordinatas  used  at  satup  tima.  If  no  ona  is  found,  t h# 
bit  number  of  t ha  bit  to  t ha  laft  of  t ha  most  significant  bit  is 

raturnad. 

t#.  FUNCTION  rgfdrOfrg  :  ragistar)  :  integer; 

RgfdrO  finds  the  rtghmost  0  in  a  register,  and  returns  its  bit 

position  in  the  coordinatas  used  at  setup  tima.  If  no  ona  is  found,  the 
bit  number  of  the  bit  to  the  laft  of  the  most  significant  bit  is 

rat  urnad . 

IS.  FUNCTION  rgfdllfrg  i  ragistar)  i  integer; 

Rgfdll  finds  the  leftmost  I  in  a  ragistar,  and  returns  its  bit 

position  in  the  coordinatas  used  at  satup  time.  If  no  ona  is  found,  the 
bit  number  of  the  bit  to  the  right  of  the  least  significant  bit  is 
rat  urnad. 

20.  FUNCTION  rgfdlOfrg  i  ragistar)  :  Integer; 

RgfdlO  finds  the  leftmost  0  in  a  ragistar,  and  returns  its  bit 

position  in  the  coordinates  used  at  setup  time.  If  no  zero  is  found, 

the  bit  number  of  the  bit  to  the  right  of  the  least  significant  bit  is 
raturnad. 


* . f . 4  logical 

21.  FUNCTION  rgandf arg 1 . arg2  ;  ragistar)  i  register; 
Rgand  returns  the  bitwise  AND  of  its  arguments. 
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22.  FUNCTION  rgnandCargl .  arg2  i  ragiatar)  t  ragiatar; 

Rgnand  raturna  t ha  bitwiaa  NAND  of  Ita  argumanta. 

23.  FUNCTION  rginvCargl:  ragiatar)  i  ragiatar; 

Rginv  raturna  t ha  bitwiaa  INVERSION  of  tta  argument . 

24.  FUNCTION  r gor ( ar g I , ar g2  i  ragiatar)  ragiatar; 

Rgor  raturna  t ha  bitwiaa  OR  of  tta  argumanta. 

25.  FUNCTION  rgnortargt ,arg2  :  ragiatar)  s  ragiatar; 

Rgnor  raturna  t ha  bitwiaa  NOR  of  ita  argumanta. 

26.  FUNCTION  r gxor ( ar g t , ar g2  t  ragiatar)  :  ragiatar; 

Rgnor  raturna  t ha  bitwiaa  EXCLUSIVE  OR  of  ita  argumanta. 

27.  FUNCTION  rgnvortargt .arg2  i  ragiatar)  t  ragiatar; 

Rgnnor  raturna  t ha  bitwiaa  inwaraion  of  t ha  EXCLUSIVE  OR  of  ita 
argumanta.  (which  ia  alao  cellad  t ha  aquivalanca  rotation.) 


A.t.7  Formatted  I/O 

28.  FUNCTION  rgrdoct(VAR  f  t  taxt)  »  intagar; 

Rgrdoct  raada  a  laignadl  octal  numbar  from  t ha  apocifiad  fila  and 
raturna  it  aa  an  intagar.  Thia  can  ba  aaaignad  diractty  to  a  variabla 
of  typa  ragiatar.  if  doairad. 

26.  FUNCTION  rgrdhanCVAR  f  t  taxt)  »  intagar; 

Rgrdoct  raada  an  taignad)  hanadacimal  numbar  from  tha  apocifiad 
fila  and  raturna  it  aa  an  intagar.  Thia  can  ba  aaaignad  dlractly  to  a 
variabla  of  typa  ragiatar.  if  doairad. 
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30.  FUNCTION  r grdb i n( VAR  f  i  Text)  i  integer; 

Rgrdoct  reads  an  (signedi  binary  number  fro*  t ha  specified  file  and 
return*  it  a*  an  integer.  This  can  b*  assigned  directly  to  a  variable 
of  type  register,  if  desired. 

3t.  PROCEDURE  rgutoctfVAR  f:t*xt;  i. width  s  integer); 

Rgwtoct  writes  i  into  file  f  as  an  octal  number  padded  on  the  left 
with  blanks  so  that  "width"  characters  are  printed.  Max  width-40. 

3?.  PROCEDURE  rgwtbintVAR  f:t*xt;  i. width  !  integer); 

Rgwtbin  writes  i  into  file  f  as  a  binary  number  padded  on  the  left 
with  blanks  so  that  "width"  characters  ar*  printed.  Max  wtdth=40. 

33.  PROCEDURE  rguthexiVAR  fitext:  (.width  :  integer); 

Rgwthex  writes  i  into  file  f  as  a  hexadecimal  number  padded  on  the 
left  with  blanks  so  that  "width"  characters  are  printed.  Max  width=40. 


A. 2  RNOPACK 

Rndpack  is  a  set  of  fairly  random  number  generators  useful  for 
stochastic  simulations.  They  ar*  listed  below. 

A. 2.1  Setting  A  New  "Seed" 

I.  PROCEDURE  rndset ( newseed  i  integer); 

Rndset  resets  the  internal  random  number  generator  mechanism 
according  using  "newseed".  It  is  only  necessary  to  call  rndsat  if 
multiple  simulation  runs  are  to  be  performed  using  different  " 


random 
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RNDPACK 

A. 2. 2  Random  Drawing  Functions 
2.  FUNCTION  rndO 1  »  raal I 

RndOl  produces  a  random  number  between  0.0  and  1.0  by  using  one 
random  number  generator  to  scramble  the  results  of  another,  thereby 
lowering  the  aut ocor rel at i on . 

J.  FUNCTION  rndneipl lambda  i  real)  i  raal I 

Rndnexp  returns  a  number  drawn  from  the  negative  evponential 
distribution  with  mean  and  standard  deviation  1. 0/lambda  (lamba  must  be 
posit ive) . 

A.  FUNCTION  rnder  I  ang(  lambda  i  real!  Ii  i  integer)  :  real! 

Rndalrang  returns  a  number  drawn  from  the  Erlang  distribution  with 
mean  (1/la~be>  and  standard  deviation  1/( sqrt (k )• lambda) .  (Minimum  k*l. 
higher  lc  makes  *  or  a  tighter  distribution.) 

5.  FUNCTION  rndnorma I ( mean ,  variance  :  raal)  t  real! 

Rndnormel  returns  a  number  drawn  from  the  Normal  distribution  with 
the  mean  end  variance  specified.  The  distribution  is  epproaimated  by 
summing  54  uniformly  distributed  random  values. 

4.  FUNCTION  rndint(low,  high  «  integer)  t  integer: 

Rndint  produces  an  integer  evenly  distributed  among  the  numbers 
from  low  to  and  including  high. 

7.  FUNCTION  rnddrawtp  i  real)  i  boolean! 

Rnddraw  returns  true  with  probability  p. 
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A. 2. 3  Data  Analytic  Facility 

ft.  FUNCTION  rndunitoratlow.  high  t 

Rnduniform  product*  a  random 
between  low  and  high.  (Nota  that 
exactly  aqual  to  low  or  high  i* 


raal >  i  raal i 

rail  numbar  uniformly  distributed 
tha  probability  of  raturning  a  valua 
vanishingly  small.) 


ft.  PROCEDURE  rndhi »t o( dat a  s  raal s  command  i  intagar); 


Rndhisto  col  tacts.  analyze*  and  plots  a  random  variabla.  It 
product*  a  histogram  automatically  scalad  to  tha  width  of  tha  papar . 
H»«i«un  number  of  bin**  200.  It*  "command***  ar*  a*  follow*: 

0  rasat  all  tall  its.  and  data  values 

1  sat  high  limit  to  "dat a" ( da ♦ au 1 t  8  10.0) 

2  sat  low  limit  to  "data'Mdefaul  t  8  -1 00) 

3  sat  number  of  bin*  to  "dat a" ( daf au I t  8  20) 

A  accept  "data"  as  a  point  to  be  plotted 

3  plot  result*  in  file  "output” 

6  plot  result*  at  tty 

sal  paper  width  to  "data"(dafeult  8  7ft  column*) 

8  reset  all  parameter*  to  default  value* 

The  print  out  include*!  tha  number  of  point*,  t he  valua  of  tha  highest 

and  lowest  point*.  the  number  of  point*  out  of  range  high  and  low  (if 

any),  the  mean,  variance,  sum,  standard  deviation,  sum  of  square*.  and 

the  auto  covariance  and  aut ocor ra I  at i on  of  adiacant  term*.  The 

following  trivial  program  show*  an  avample  of  it*  use: 


program  *; 

var  i  i  integer; 

function  rnder I eng< I e-bda  i  real;  h  i  integer)  i  real;  antarn; 
procedure  rndhi *t o< dat a  i  real;  command  i  (nt agar ); ext arn ; 
begin 

for  i  i*  1  to  1000  do  rndhi *t o( rnder 1 eng( S . 0 . A ) . A  )  1 

rndhistotO.0,5); 

and . 

This  produces  the  output  * hown : 
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50000 

0> 

50000 

0> 

-  7  . 

50000 

0> 

-6  . 

50000 

0> 

50000 

0> 

50000 

0> 

50000 

0> 

-2 . 

50000 

0> 

- 1 . 

50000 

0> 

OOOOOE'O  I 

7> 

s'. 

OOOOOE-O  t 

1 3* >xxxxxxxxxxxxxx 

1 . 

50000 

2  07  >xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

2. 

50000 

262>XXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

3 

50000 

1 5*  >XXXXXXXXXXXXXXXXX 

4. 

50000 

82  7XXXXXXXXX 

5. 

50000 

32  >XXX 

4. 

50000 

1 7  >X 

7  . 

50000 

8  > 

8 

50000 

6  > 

0. 

50000 

0> 

NUM  POINTS: 

1000  LOWVAL  *  t .826464O32E-0I 

MIOHVAIUE-  1 . t78*l74S2E*CI 

POINT ( 5 )  WERE  TOO  HIGH  0  POINT(S)  WERE  TOO  LOW 
EANI  2.074368000  VARIANCE1  2.345632*7* 

un=  2. 076 3*80 OOE* 0 3 

Un$Q:  1 . »2220330*E*0*  SUM  PROD:  8 .85*80  I*  I6E  +  03 
TO  DEV:  I . 53806  1274 
UTO  COVAR I ANC£:-4. 7*2*24 10RE-03 
UT0C0RRELATI0N:-2.87 t2*3«02E-03 


Th*  cod#  for  thio  rout  ino  to  not  vary  conpl  icatod.  %o  t  ho  umor  may 
to  copy  it  and  Modify  it  for  hit  or  har  own  spoeial  application. 


with 
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